모놀리스와 마이크로서비스 아키텍처

최근 IT 관련 아티클들을 보면 모놀리스에서 마이크로서비스 아키텍처로 전환한다는 말이 많이 보게됩니다. 모놀리틱와 마이크로서비스는 무엇일까요? 이 둘은 모두 소프트웨어 아키텍처 패턴을 일컫는 개념입니다. 특히 비교적 최근 마이크로서비스 아키텍처의 등장으로 두 패턴은 자주 비교됩니다. 살펴보면 두 패턴은 각자 상반된 장단점을 가지고있습니다. 이번 글에서 이 두 패턴에 대해 알아봅시다.

모놀리스 아키텍처

개념

모놀리스(Monolith) 아키텍처는 하나의 소프트웨어를 구성하는 모든 모듈과 코드를 한 프로젝트에서 관리하는 것을 말합니다. 애플리케이션을 기동하려면 이 단일 프로젝트만 실행시키면 됩니다. 아주 익숙한 방식입니다.

(출처: https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/)

예시

모놀리식 아키텍처로 개발하는 구체적인 예시를 봅시다. 우리가 쇼핑몰 웹사이트를 위한 백엔드 서버를 간단하게 만들어본다고 하죠. 프로젝트 구조는 다음과 같은 모양을 띌 것입니다.

app/
  domain/
    users/
      model.py
      repository.py
    products/
      model.py
      repository.py
    payment/
      model.py
      repository.py
  service/
    user_service.py
    product_service.py
    payment_service.py
  controller/
    user_controller.py
    product_controller.py
    payment_controller.py
  main.py
  config.json

서버를 구성하기 위한 모든 모듈과 코드가 app/ 내에 존재합니다. 즉 하나의 프로젝트 안에 담깁니다. 또한 이 서버를 기동하기 위해서는 main.py 만 실행시키면 됩니다.

모놀리스 아키텍처는 이렇게 단순하며 전통적인 우리 상식에 들어맞는 아키텍처 패턴입니다.

장단점

모놀리스 아키텍처로 소프트웨어를 구성하면 다음과 같은 점이 좋습니다.

• 한 프로젝트 내에 모든 모듈과 코드가 있으므로 개발이 간단하고 리뷰가 용이합니다.
• 소프트웨어 구조가 비교적 단순해서 애플리케이션을 구성하는 큰 그림을 보는데 편리합니다.
• 애플리케이션 기동에 main.py 만 실행시키면 되므로, 배포하기 쉽습니다.
• 디버깅이나 비교적 장애 대응이 비교적 쉽습니다.

하지만 다음과 같은 한계를 가집니다.

• 애플리케이션 코드가 점점 많아지고 서비스가 확장되면 전체 구조나 코드 흐름을 쉽게 이해하기 어렵습니다.
• 한 프로젝트 내에 있는 코드이므로, 모든 코드가 결합되어 있습니다. 이 때문에 코드 변경이 두렵고 확장하기 어려워집니다.
• 위와 같은 이유로 개발 속도도 느려집니다. 코드를 작성하려면 전체 코드를 다 이해해야 하기도 합니다.
• 한 번에 테스트해야 할 양도 점점 늘어나 테스트 속도가 매우 느려집니다. 빌드 역시 마찬가지입니다.
• 최신 기술 스택이 나와도 쉽게 도입하기 어렵습니다. 모든 코드에 영향이 가기 때문입니다.

보통 기능 개발과 속도가 중요한 사업 초기에는 애플리케이션을 모놀리스 아키텍처로 구성합니다.

마이크로서비스 아키텍처

개념

마이크로서비스(Microservice) 아키텍처는 하나의 소프트웨어를 구성하는 컴포넌트들을 독립적인 프로젝트들로 분리하여 관리하는 것을 말합니다.
이 각각의 컴포넌트들을 마이크로 서비스라고 부를 수 있습니다. 개발과 배포도 이렇게 분리된 마이크로서비스 단위로 진행합니다. 즉 하나의 소프트웨어가 정상적으로 동작하기 위해서는 이를 구성하는 각각의 마이크로서비스가 모두 정상 작동해야 합니다. 이러한 방식은 보통 소프트웨어가 커지고 복잡해질 때 필요합니다.

(출처: https://www.n-ix.com/microservices-vs-monolith-which-architecture-best-choice-your-business/)

예시

마이크로서비스 아키텍처로 개발하는 구체적인 예시를 봅시다. 위에서 예시로 든 쇼핑몰 웹사이트 백엔드 서버를 구성하면 다음처럼 됩니다.

먼저 쇼핑몰 웹사이트 백엔드 프로젝트는 크게 다음처럼 3가지 도메인으로 나눌 수 있습니다.

• 사용자 관련 도메인 (Users)
• 상품 관련 도메인 (Products)
• 결제 관련 도메인 (Payment)

프로젝트도 각 도메인에 맞게 3가지로 나뉘게 됩니다.

# Users
app/
  domain/
    model.py
  service/
    user_service.py
  controller/
    user_controller.py
  main.py
  config.json

# Products
app/
  domain/
    model.py
  service/
    product_service.py
  controller/
    product_controller.py
  main.py
  config.json

# Payment
app/
  domain/
    model.py
  service/
    payment_service.py
  controller/
    payment_controller.py
  main.py
  config.json

세 가지 도메인은 각각 다른 프로젝트에서 개발되고 배포됩니다. 즉 Users, Products , Payment 프로젝트에서 각각 main.py 로 서버를 기동하고, 서버 3개가 동시에 떠있는 상태여야 쇼핑몰 웹사이트 백엔드 시스템이 정상적으로 동작한다고 할 수 있습니다.

이 세 서버는 필요한 경우 서로 HTTP 통신하며 협력합니다. 예를 들어 결제 관련 서비스에서 유저 정보가 필요한 경우 Payment 서버에서 Users 서버로 REST 요청을 보내고 응답받습니다. 이처럼 마이크로서비스 간에 협력을 통해 사용자에게 최종 기능을 제공합니다.

마이크로서비스 아키텍처는 모놀리스보다 조금 더 복잡하고 해야 할 일도 많은 듯 하지만, 전체 서비스가 복잡해질수록 서비스 개발과 배포를 빠르게 진행할 수 있는 장점이 뚜렷해집니다. 또한 각 마이크로서비스 별로 프로그래밍 언어(파이썬, 자바 등)이나 데이터베이스(MySQL, MongDB 등)를 따로 사용하는 등 기술 스택을 더 자유롭게 가져갈 수 있습니다.

장단점

마이크로서비스 아키텍처로 소프트웨어를 구성하면 다음과 같은 점이 좋습니다.

• 각 마이크로서비스가 모놀리스보다 작은 규모이기 때문에 마이크로 서비스별로 보면 코드 구조나 흐름을 이해하기 쉽습니다.
• 전체적으로 분리가 되어있기 때문에 마이크로서비스간 결합이 강하지 않습니다. 각 서비스별로 수정이나 확장을 시도하기 편합니다.
• 위와 같은 이유로 개발 속도가 빨라집니다. 특히 각 마이크로서비스를 담당하는 전담 팀들이 있을 때 그렇습니다.
• 한 번에 테스트할 양도 마이크로서비스 단위로 나뉩니다. 테스트와 빌드, 배포 속도가 빨라집니다.
• 마이크로서비스별로 사용할 컴퓨팅 리소스(cpu, memory, etc)를 다르게 줄 수 있습니다. 또한 서버 개수도 다르게 둘 수 있습니다. 이는 요청 증가에 따른 서버 확장에 용이합니다.
• 기술 스택도 각 마이크로서비스 별로 다르게 가져갈 수 있습니다. 예를 들어 Users 서버는 Java, Products 는 파이썬, Payment 는 JS로 개발할 수 있습니다. 이처럼 각 마이크로서비스는 독립적인 환경에서 개발되기 때문에 기술 도입이 유연해집니다.

하지만 다음과 같은 단점들이 존재합니다.

• 각 서비스들이 분산되어 있기에 여러 연관된 서비스를 통합하여 테스트할 때 난이도가 높아집니다.
• 처음에 어떤 기준으로 마이크로서비스를 나눌지 결정하는 것이 어렵습니다. 잘못 나누면 마이크로서비스간 결합도는 높아지고 관리 비용이 늘어날 수 있습니다.
• 각 담당 팀에서 마이크로서비스만 집중해서 개발하다보면 서비스의 전체 큰 그림을 파악하기 어려울 때가 있습니다. 이런 큰 그림과 흐름을 파악하기 위해 커뮤니케이션 비용이 들어갑니다.
• 여러 서비스에 걸친 분산 트랜잭션 처리 등 분산 시스템 환경에서 고민할 문제들이 많습니다.

정리

• 모놀리스 아키텍처는 하나의 소프트웨어를 하나의 프로젝트로 개발하는 아키텍처입니다.
  • 한 프로젝트 내에 모든 모듈과 코드가 담겨있습니다.
  • 모든 개발자가 이 프로젝트에서 개발하고 협업합니다.
  • 규모가 작은 프로젝트의 경우 코드 파악도 용이하고, 빌드와 배포도 빠릅니다.
  • 서비스 초기에 프로젝트 규모가 작을 때 주로 사용됩니다.
• 마이크로서비스 아키텍처는 하나의 소프트웨어를 여러 독립된 프로젝트로 나누어 개발하는 아키텍처입니다.
  • 하나의 서비스는 여러 마이크로 서비스로 분리됩니다,
  • 각 마이크로서비스 단위로 개발하고 배포합니다. 보통 이 마이크로서비스 단위로 개발팀이 꾸려집니다.
  • 규모가 큰 프로젝트의 경우 마이크로 서비스 단위로 코드를 파악하기 용이하고, 빌드와 배포도 빠릅니다.
  • 서비스가 성장하고 프로젝트 규모가 커질 때 모놀리식에서 마이크로서비스로 전환하곤 합니다.

더 알아두면 좋은 것들

링크

• 우아콘2020 - 배달의민족 마이크로서비스 여행기 (opens new window)
• 쿠팡 테크 블로그 - 행복을 찾기 위한 우리의 여정 (opens new window)
• 마이크로서비스 관계 패턴 - 읽기와 쓰기 분리: CQRS패턴 (opens new window)
• 마이크로서비스 관계 패턴 - 통신 패턴과 Event driven architecture (opens new window)